Systems and methods for communication, storage and processing of data provided by an entity over a blockchain network

ABSTRACT

A computer-implemented method of making a decision on a blockchain is provided. The method comprises providing a blockchain voting commitment transaction (2) redeemable by means of a first signature (σ(Am), σ(Bm)) associated with a selection (A, B) and a second signature (σ(A), σ(B)) associated with the selection, providing each of a plurality of participants (Ui) with at least one share (kA,i, kB,i) of at least one respective secret value (kA, kB) wherein a threshold number of shares is required in order to execute said second signature, and submitting the blockchain voting commitment transaction (2) to the blockchain.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Pat. Application No.16/642,873, filed Feb. 27, 2020, entitled “SYSTEMS AND METHODS FORCOMMUNICATION, STORAGE AND PROCESSING OF DATA PROVIDED BY AN ENTITY OVERA BLOCKCHAIN NETWORK,” which is a 371 National Stage of InternationalPatent Application No. PCT/IB2018/056576, filed Aug. 29, 2018, whichclaims priority to United Kingdom Patent Application No. 1713800.9,filed Aug. 29, 2017, the disclosures of which are incorporated herein byreference in their entirety.

This invention relates generally to cryptographically-enforced datarecording and processing systems. In particular, the invention relatesto a technical solution for communicating, recording and/or storing dataprovided to the system by an entity via or over a blockchain network.The data may be indicative of, for example, a selection, choice,feedback and/or decision. The invention provides techniques for securestorage and communication of such data between entities over theblockchain network, and ensures the integrity of the data that istransferred and used post-transfer. It also alleviates issues relatingto identification of the source of such data on a network, to preventauthorised activity. The invention is suited for, (but not limited to)voting, electronic feedback submission, or counting applications, orother applications where data integrity, source concealment andenforcement of usage quotas or limits may be of importance.

In this document we use the term ‘blockchain’ to include all forms ofelectronic, computer-based, distributed ledgers. These includeconsensus-based blockchain and transaction-chain technologies,permissioned and un-permissioned ledgers, shared ledgers and variationsthereof. The most widely known application of blockchain technology isthe Bitcoin ledger, although other blockchain implementations have beenproposed and developed. While Bitcoin may be referred to herein for thepurpose of convenience and illustration, it should be noted that theinvention is not limited to use with the Bitcoin blockchain andalternative blockchain implementations and protocols fall within thescope of the present invention. The term “user” may refer herein to ahuman or a processor-based resource.

A blockchain is a consensus-based, electronic ledger which isimplemented as a computer-based decentralised, distributed system madeup of blocks which in turn are made up of transactions. Each transactionis a data structure that encodes the transfer of control of a digitalasset between participants in the blockchain system, and includes atleast one input and at least one output. Each block contains a hash ofthe previous block to that blocks become chained together to create apermanent, unalterable record of all transactions which have beenwritten to the blockchain since its inception. Transactions containsmall programs known as scripts embedded into their inputs and outputs,which specify how and by whom the outputs of the transactions can beaccessed. On the Bitcoin platform, these scripts are written using astack-based scripting language.

In order for a transaction to be written to the blockchain, it must be“validated”. Network nodes (miners) perform work to ensure that eachtransaction is valid, with invalid transactions rejected from thenetwork. Software clients installed on the nodes perform this validationwork on an unspent transaction (UTXO) by executing its locking andunlocking scripts. If execution of the locking and unlocking scriptsevaluate to TRUE, the transaction is valid and the transaction iswritten to the blockchain. Thus, in order for a transaction to bewritten to the blockchain, it must be (i) validated by the first nodethat receives the transaction - if the transaction is validated, thenode relays it to the other nodes in the network; (ii) added to a newblock built by a miner; and (iii) mined, i.e. added to the public ledgerof past transactions. Once recorded, the data in any given block cannotbe altered retroactively without altering all subsequent blocks and acollusion of the network majority.

Transactions involve the transfer of one or more tokens from one node toanother node. Tokens may represent future control of network resources.In some cases, the tokens may represent an asset or value, but notnecessarily. For example, in some cases, the tokens may be understood asa cryptocurrency. However, the present application is not limited toimplementations in the context of cryptocurrency and is more broadlyunderstood as relating to blockchain networks for distributed transferof control tokens.

A blockchain serves as a public ledger that can record transactionsbetween parties in a verifiable and permanent way. Blockchains possessnumerous properties, such as irrevocability of information storedon-chain and trust established through decentralized consensus, whichmake them suitable for use in various applications. One such applicationis electronic voting. It should be noted that the term “voting system”is not limited herein to political or administrative contexts, but isused in a generic sense to simply mean a system which enables aselection, choice, decision or parameter (i.e. a vote) to betransferred, recorded, stored, processed and/or registered in some way.Thus, the invention relates to improved communication, storage andsecurity of data between entities.

Many types of computer-implemented systems need to enable an indicationof a choice/decision, or other data, to be communicated across anetwork, so that the data can be acted upon or processed in some way. Inmany cases, it is desirable to be able to enforce certain rules orcriteria relating to the number of times that a selection can be made.In other words, there may be a quota or limit to the number of times aselection or choice can be made. For the sake of convenience and ease ofreference only, we may refer to such a system as an “e-voting” systembut this should not be construed as limiting the invention to politicalor administrative contexts. Alternatively, the term “data recordingsystem” may be used to reflect the wider applicability of the invention.The invention is not limited with regard to the type or nature of datareceived, recorded and stored.

Recently, there has been a growing interest in exploiting onlinetechnologies to design protocols for secure electronic voting. The goalof these endeavours is to allow a group of users to make a shareddecision based on individual preferences, preferences which are keptsecret. Challenges related to electronic voting include denying a secondparty the ability to determine a user’s vote, ensuring theirrevocability of a vote, as well as providing necessary transparencythroughout the process to garner voter trust in the process.

The introduction of the blockchain as a basis of cryptocurrencyprotocols provides for the exploitation of the immutability andtransparency properties of these distributed ledgers. These ledgers incombination with available cryptographic solutions present a uniqueopportunity to use the blockchain as an effective replacement of thetrusted third parties typically present in electronic (servers) andnon-electronic voting processes.

The wide adoption by the global community of Information Technology, andthe Internet in particular, for usage in a variety of pre-existingservices, inevitably led to electronic voting considerations. While webbased polls are common method of garnering user sentiment, there hasbeen notable opposition the usage of electronic voting for electionsrelated to public office and other contexts. In the face of thisresistance, for electronic voting to achieve greater success, proposedsystems will be tasked with satisfying a variety of socio-technicalhurdles.

Some of the criteria deemed desirable which electronic voting systemsmust strive to achieve are:

-   Correctness: all votes correctly taken into account; i.e. invalid or    unauthorized ballots excluded while all valid votes count toward the    final result.-   Privacy: the vote not known to participants different from the voter    himself.-   Prevent double voting: no vote submitted twice, i.e. an attacker    should not be able to copy a vote submitted by another voter    already.-   Eligibility: only authorized voters can cast their ballot in the    protocol.-   Verifiability to verify that a vote has been correctly taken into    account.

The advent of blockchain technology via the cryptocurrency Bitcoin haspresented an opportunity for utilising the blockchain’s properties inthe construction of electronic voting protocols. Blockchain itself is animmutable public ledger that removes the need for a trusted third partyin the validation of transactions. These characteristics are thought tobe applicable to electronic voting by accommodating and/or enabling oneor more of the five previously stated criteria.

The blockchain constitutes a suitable environment where votes andopinions may be publicly and permanently recorded in order to avoidmanipulation of any kind of the votes. Despite this ability, there arenumerous issues that are to be addressed in order to create a securevoting on the blockchain. This ranges from preventing multiple ballotssubmissions to maintaining the users’ privacy and credentials checking.

Decentralisation is one of the biggest challenges for online e-votingand rating’s protocols: usually existing solutions are constructed insuch a way to prevent abuse but they rely on a central authority tovalidate and take into account votes or feedback.

The central authority may use different cryptographic primitives, suchas blind signatures and homomorphic encryption, to add secrecy andeligibility’s verification to the ballot vote. In Chaum’s protocolparticipants send their votes to mixing authorities that, using the MixNets set-up, reshuffle and encrypt the vote before their broadcast, inorder to disguise vote-voters link. This is described in greater detailin Chaum, D. L. (1981) - “Untraceable electronic mail, return addresses,and digital pseudonyms”, Communications of the ACM, 24(2), 84-90.

Thus, it is desirable to provide a Bitcoin-compatible voting protocolwhere voters utilise a Bitcoin transaction to cast their vote for theirpreferred candidate — among two possible options — as well as commit anamount of bitcoins or tokens to the winning candidate. This protocolutilises a distributed key shares scheme to facilitate the rewarding ofthe candidate who would have won sufficient votes.

Such an improved solution has now been devised.

Thus, in accordance with the present invention there are providedmethods as defined in the appended claims.

In accordance with the invention there may be provided acomputer-implemented method of voting on a blockchain, comprising:providing each of a plurality of voters with at least one share of asecret value, wherein each secret value is associated with a selection;providing a commitment transaction redeemable to reveal a winningselection upon provision of both: (i) a first signature determinablefrom a secret value of the winning selection; and (ii) a secondsignature indicative of an identity of the winning selection; andsubmitting the commitment transaction to the blockchain, wherein thesecret value of the winning selection is determinable using a number ofvoting items provided by at least one voter, each of the voting itemscomprising at least one share, and wherein the number exceeds apredetermined value.

By providing such a method, users of the blockchain are able to castvotes securely in a tamper-proof first-past-the-post style votingsystem.

At least one voter may add to the commitment transaction at least onesigned input representative of a cryptographic asset.

This provides the advantage of disincentivising frivolous or maliciousparticipation in the voting process.

The method may further comprise the step of providing a returntransaction redeemable, upon satisfaction of a locktime condition, toreturn at least a portion of the cryptographic asset to at least onevoter.

This provides the advantage of a mechanism for minimising loss of fundsin the event of no winning selection.

The commitment transaction may comprise an m-of-n multisignature redeemscript, and at least one voting item may be added to the redeem script.

This provides the advantage of enabling the storage and publicvisibility of the at least one voting item.

At least one voting item may be encrypted with a first public key of atleast one selection.

This provides the advantage of enabling only the chosen selection todecrypt the voting item and gain access to the share.

At least one voting item may comprise at least one identification itemidentifying at least one selection.

Upon successful decryption of the voting item, this provides theadvantage of increasing the ease with which the share can besubsequently identified.

At least one voting item may comprise a concatenation of at least oneshare and at least one identification item.

The step of providing the shares to the voters may comprises at leastone of: (i) a dealer entity providing the shares to the voters; and (ii)the voters generating shares.

This enables both a dealer-based voting system and a dealer-less votingsystem, thereby increasing the versatility of the voting method.

The method may further comprise the step of obscuring which voterprovides which voting item prior to submission of the commitmenttransaction to the blockchain.

This prevents a voter from being identified from their voting item,thereby providing the advantage of increasing the security of the votingmethod.

The method may further comprise the step of providing a redemptiontransaction arranged to redeem the commitment transaction.

This provides the advantage of a simple way to indicate to the votersthe identity of the winning selection.

The method may further comprise the step of validating at least oneshare using at least one second public key.

This enables a voter to check the validity of a share, thereby providingthe advantage of increasing the robustness of the voting method.

The plurality of voters may collaborate in combining at least one subsetof shares to determine at least one said second public key.

This provides a means of decentralising at least a portion of the votingmethod, thereby providing the advantage of further increasing theversatility of the method.

Additionally or alternatively, in accordance with the invention theremay be provided a computer-implemented method of determining a winningselection of a vote on a blockchain, comprising the steps of:determining at least one share of at least one secret value from atleast one voting item, wherein each secret value is associated with aselection; determining a secret value of the winning selection using anumber of shares thereof provided by the at least one voting item,wherein the number exceeds a predetermined value; determining a firstsignature from the secret value of the winning selection; and redeeminga commitment transaction to reveal the winning selection by providingboth: (i) the first signature; and (ii) a second signature associatedwith an identity of the winning selection.

By providing such a method, the identity of a winning selection of avoting method carried out on a blockchain can be determined and checkedin a secure and transparent manner.

The invention also provides a system, comprising:

-   a processor; and-   memory including executable instructions that, as a result of    execution by the processor, causes the system to perform any    embodiment of the computer-implemented method described herein.

The invention also provides a non-transitory computer-readable storagemedium having stored thereon executable instructions that, as a resultof being executed by a processor of a computer system, cause thecomputer system to at least perform an embodiment of thecomputer-implemented method described herein.

The present application describes systems and methods which facilitatesecure, cryptographically enforced and efficient implementation ofschemes for encrypting, validating, and broadcasting data items that aresubmitted by users to a blockchain. The users may, in some usefulapplication, be participants in a voting or feedback platform. In someimplementations, the present application provides protocols that aredesigned to prevent submissions of data from malicious actors. This canpreserve the integrity and reliability of results which are produced bythe system based on the received data.

These and other aspects of the present invention will be apparent fromand elucidated with reference to, the embodiment described herein. Anembodiment of the present invention will now be described, by way ofexample only, and with reference to the accompanying drawings, in which:

FIG. 1 illustrates a schematic showing the interaction of threetransactions of the present invention;

FIG. 2 is a table showing the relationship between a number of voters, athreshold number of votes required for a selection to be determined awinner, and a degree of a polynomial in accordance with the invention;

FIG. 3 shows a flow chart illustrating the present invention;

FIG. 4 shows a voting commitment transaction;

FIG. 5 shows two winner payment transactions;

FIG. 6 shows a refund transaction; and

FIG. 7 is a schematic diagram illustrates a computing environment inwhich various embodiments can be implemented.

The present application describes a system of Threshold Secret ShareVoting (TSSV), which is a system where a set of voters is asked tochoose between a pair of candidates where the winning candidate receivesx BTC committed by each voter. The winning candidate must receive both amajority of votes and a number of votes past a specified threshold. TheTSSV protocol utilises the distribution of private key shares, and isdesigned such that any bitcoins committed are recoverable if one or moreparticipants act maliciously or do not follow protocol expectations.

The abbreviation “BTC” may be used herein as a shorthand for anyvariation of the Bitcoin protocol. It should not be interpreted as beingrestricted to or indicative of any one particular Bitcoin-relatedprotocol.

Secret Sharing

A threshold cryptosystem is defined by (t ; n) - threshold, where n isthe number of parties and t + 1 is the minimal number of partiesrequired to reconstruct a secret. Secret Sharing schemes are examples ofthreshold cryptosystems, whereby a secret k is divided among n players,such that at least t + 1 participants are required to collaborate inorder to reconstruct k. The knowledge of any t pieces of the secret kleaves the latter undetermined.

Shamir’s secret sharing (or SSS) is based on polynomial interpolationand without loss of generality the secret is assumed to be an element ofa finite field F. The scheme comprises a dealer (dealerless versionsalso exist), a set of n participants U₁, ..., U_(n) and an accessstructure A, i.e. the groups of players able to reconstruct the secret.This is described in greater detail in Shamir, A. (1979) “How to share asecret”, Communications of the ACM, 22(11), 612-613.

For Shamir’s solution, an arbitrary random secret is stored as f(0) in at degree polynomial f (x) and only player i can calculate its share f(x_(i)). If t + 1 out of n players collaborate, they can reconstruct anypoint on f (x), with their shares (of the key k) k₁, k₂, ..., k_(n)which correspond to f (x₁), f (x₂), ..., f (x_(n)) using LagrangePolynomial Interpolation.

Using the Lagrange Polynomial Interpolation, a function f (x) withdegree t can be reconstructed with t + 1 points

p = {(x₁, f(x₁)), (x₂, f(x₂)), ..., (x_(t + 1), f(x_(t + 1)))}

$f(x) = {\sum\limits_{i \in p}{f( x_{i} )}}{\prod\limits_{j \in p,j \in i}{\frac{x - x_{i}}{x_{i} - x_{j}} = {\sum\limits_{i \in p}{f( x_{i} )}}}}b_{i,p}(x)$

where

$b_{i,p}(x) = {\prod\limits_{j \in p,j \in i}\frac{x - x_{i}}{x_{i} - x_{j}}}$

Note that b_(i,p) (x_(i)) = 1 and b_(i,p) (x_(j)) = 0.

In the presence of a dealer the dealer simply selects a secret α_(o) =k, assumed to be an element of the finite field F of size p (p prime),and randomly pick t — 1 positive integers a₁, ..., a_(t-1), whichrepresent the coefficient of the polynomial f (x) = a_(o) + a₁x +a₂x²+... The dealer then computes n points (x_(i,) f (x_(i)))belongingto the polynomial and distribute it to the participants.

In the dealerless shares distribution phase:

-   1. Each player U_(i) is assigned x_(i) which is known by everyone.    Each x_(i) has to be unique.-   2. Each player U_(i) generates a random polynomial f_(i)(x) with    degree t.-   3. Each player U_(i) secretly sends (encrypted with the recipients’    public key) every other player their respective point on the    polynomial, f_(i)(x_(j))mod n.-   4. Each player U_(i) sums all their received f₁(x_(i)), f₂(x_(i)),    ... f_(p) (x_(i)) (all mod n, where n is the order of the group    generated by the point G on the elliptic curve) to form

k_(i) = f(x_(i))mod n

which is a share on the polynomial f (x) mod n.

An important element of the threshold signature calculations is thedetermination of k × G where k is the secret key and G is a point on theElliptic Curve.

If f(x) is a t-degree polynomial, secret k can be interpolated by k =Σ_(i∈π) b_(i,π)k_(i) where π is a size t + 1 subset of shares k_(a),k_(b), ..., k_(t), k_(t+1) and b is an interpolating factor. π is agroup of t + 1 players collaborating to calculate k × G withoutrevealing their share k_(i). k is the x = 0 point on a t-degreepolynomial

-   Each player U_(i) calculates a part b_(i,π)k_(i) × G-   All players in π add their part together (reconstructing the secret    k via Lagrange interpolation) giving:-   b_(a, π)k_(a) × G + b_(b, π)k_(b) × G + ⋯ + b_(t + 1, π)k_(t + 1) × G = k × G

This process of calculating Q = kG is referred to as Secret ShareJoining.

Public Verifiable Secret Sharing Schemes

In the TSSV protocol it is desirable that voters be able to verify thatthey are given correct secret shares. Indeed, if inconsistent shares aredistributed among the players, the incorrect share/votes of the voterswould fail to contribute to the voter’s preferred candidate. For theshares verification we will employ the Publicly Verifiable SecretSharing scheme (PVSS) which allows voters to verify their own shares aswell as the shares of the other voters. This is described in greaterdetail in Stadler, M. (1996, May), “Publicly verifiable secretsharing” - International Conference on the Theory and Applications ofCryptographic Techniques (pp. 190-199), Springer Berlin Heidelberg.

In a PVSS scheme, each participant U_(i) has a decryption functionD_(i), which is able to access the information encrypted with thecorresponding public encryption function E_(i). In this way, the dealercan use the public encryption function to distribute the shares andpublish them in this form

K_(i) = E_(i)(k_(i)), i = 1, ..., n.

The encrypted shares can be, hence, publicly verified by any interestedindividual as we shall detail below. The participants can, not onlyverify their own shares, but anybody can verify that the participantsreceived correct shares, i.e. whether the dealer was honest or not.

The main steps of the protocol are:

-   1- Secret sharing: the dealer runs an algorithm Share(k) = (k₁, ...,    k_(n)) to compute the shares and distribute them among the    participants.-   2- Reconstruction: participants can reconstruct the secret by    running the algorithm Recover, such that Recover ({D_(i)(K_(i)) |i ∈    A}) = k.-   3- Verification: an algorithm PubVerify is used to validate the    encrypted shares. If we run the algorithm PubVerify({K_(i)|i ∈ A}) =    1 → Recover ({D_(i)(K_(i)) |i ∈ A}) = u and u = k then the dealer is    honest and the shares are consistent.

The PVSS scheme can be interactive or non-interactive depending onnecessity in the recovery phase.

De-Linking Outputs From Inputs in Bitcoin Transaction

The design of the voting protocol is such that the transaction that paysthe winning candidate also contains the votes of the individual voters.In order for participants in the voting protocol, the candidates, or anyexternal party, not to know the vote (and/or its encrypted value) of anyanother participant, it is important to incorporate a solution allowingeach participant to contribute their encrypted vote without any otherparticipant being able to link this encrypted value to its voter source.

This requirement is similar to that of the popular Bitcoin coin mixingsolution CoinJoin, which is described in greater detail at Maxwell, G.(2013, August) - “CoinJoin: Bitcoin privacy for the real world” - Poston Bitcoin Forum. http://tinyurl.com/gn6kmx4. In CoinJoin each of a setof participants contribute and represent one of the inputs of a Bitcointransaction; this transaction contains multiple outputs where each ofthe output addresses is provided by participants of the inputs. In orderto strengthen the anonymity of the coin mixing process it is importantto delink the input participant from their output address. To addressthis issue, a variety of shuffling solutions have been developed whereparticipants may provide their output addresses without any otherparticipant or external adversary being able to associate a participantto a specific output address.

Shuffling solutions include CoinShuffle (described in greater detail atRuffing, T., Moreno-Sanchez, P., & Kate, A. (2014, September),“CoinShuffle: Practical decentralized coin mixing for Bitcoin” -European Symposium on Research in Computer Security (pp. 345-364),Springer International Publishing), CoinShuffle++ (described in greaterdetail at Ruffing, T., Moreno-Sanchez, P., & Kate, A. (2016) - “P2Pmixing and unlinkable Bitcoin transactions” NDSS’17.https://goo.gl/QrfMhp), and Circle Shuffle.

Threshold Secret Share Voting

Referring to FIGS. 1 to 6 , a method of making a decision on ablockchain is provided. The decision may be in the form of a desiredcourse of action, a preferred candidate in an election, or any otherdecision. A number of participants, or voters, are provided with sharesin respective secret values associated with one or more outcomes of thedecision. The outcomes may be candidates up for election. Theparticipants then vote for their preferred outcome, selection, orcandidate, by providing to a first, or commitment, transaction 2 aninput 4 containing a share associated with that outcome. The commitmenttransaction 2 (see FIG. 4 ) is arranged to be redeemable only uponprovision of both a first signature (6 a, 6 b) associated with one ofthe outcomes, and a second signature (8 a, 8 b) associated with thatoutcome. In FIGS. 4 to 6 , a signature for public key X is denoted σ(X).Upon provision of at least a threshold number of shares of a secretvalue, enough information is available to execute the second signature(8 a, 8 b), and therefore to satisfy the requirements of the commitmenttransaction 2 and reveal the outcome and/or enact the decision.

For the Threshold Secret Share Voting (TSSV) protocol one imagines ascenario where a set of participants {U_(i)} have a choice of voting forone or more selections, or candidates. In this example, there are twocandidates designated A and B. Each candidate has a main private-publickey pair ((PrivA_(M), PubA_(M)) and (PrivB_(M), PubB_(M))) where thepublic keys are made available to all voters. Each voter has one voteand a winning candidate is the candidate with:

-   the most votes,-   AND enough votes past a specified threshold.

As an example, if there are to be 9 participants (voters) then thewinning candidate can be asked to receive at least 5 votes.

In combination with their vote, voters are asked to commit to a certainamount of funds (e.g. bitcoins) alongside their vote. The accumulatedcommitted funds from all voters will be given to the winning candidate.These funds may be seen as, or act as, a reward to the winner, or adisincentive for frivolous or malicious participation in the votingprocess.

The TSSV protocol uses three transactions. These transactions arelabelled the Vote Commitment Transaction 2 (FIG. 4 ), Winners Payment(or Redemption) Transaction 10 (FIG. 5 ), and the Refund Transaction 12(FIG. 6 ). These transactions have the following responsibilities.

Vote Commitment Transaction: The Vote Commitment Transaction (VCT) 2 isthe transaction which contains both the bitcoin commitment and the votecommitment of each voter. For the proposed TSSV design, this transaction2 comprises inputs 4 from the entire set of voters, though not allvoters are required to provide votes. The VCT 2 records all user votesas well as pools the bitcoin commitments at one output 14. These votesare encrypted.

Refund Transaction: The Refund Transaction (RT) 12 is a failsafe measurefor voters to recover their committed funds if a candidate is unable tocollect the accumulated bitcoins of the voters before a specified time.The RT 12 is created and signed after users have voted and the VCT 2 hasbeen created (but not submitted).

Winners Payment Transaction: The Winners Payment Transaction (WPT) 10,or redemption transaction, is the transaction that pays a winningcandidate the accumulated bitcoins. The winning candidate will be theonly person, candidate or otherwise, who would be able to collect thepooled bitcoins. FIG. 5 shows two possible redemption transactions 10 a,10 b: (a) shows the redemption transaction 10 a in the event thatcandidate A wins, and (b) shows the redemption transaction 10 b in theevent that candidate B wins.

A visual representation of the interplay between these threetransactions 2, 10, 12 and the pooled bitcoins is shown in FIG. 1 .

The Voting Commitment Transaction (VCT) 2 is the transaction thatcontains the user votes. Of the two commitments (vote and bitcoins) avoter must make for the VCT, the process of making the BTC funds is theone most easily understood and the one best facilitated by the Bitcoinprotocol.

In the case of the bitcoin commitment, each user utilises the unspentBTC at a specific address they control/own and includes this as an input4 of the commitment transaction 2, and signs their input 4. The voter’sinput 4 in the commitment transaction 2 is only signed by the voterprovided that the voter is satisfied with the other available details ofthe commitment transaction 2. The refund transaction 12 should also havebeen signed by all relevant parties. Each user is expected to commit thesame amount (xBTC) of bitcoins to their vote, though this is notessential.

In the case of the ‘vote commitment’, a vote v_(i) by a voter U_(i) fora candidate B in the context of the TSSV protocol is expressed as theconcatenation of: a secret share k_(B,i) of a key k_(B) given to U_(i);and an identification value for candidate B. The vote may be expressedin the following manner: v_(i) = k_(B,i)|| IDCandidateB where k_(B,i) isthe share held by voter U_(i) of the key k_(B) and || representsconcatenation.

The key share component of v_(i) will play a part in allowing thecandidate B to claim the accumulated committed funds of all voters ifcandidate B is able to garner sufficient votes. The vote v_(i) is notnecessarily embedded into the VCT 2 as it is; it is preferably firstencrypted with the public key of the candidate the voter U_(i) wants tovote for (Candidate B in this example). The encrypted vote can berepresented as v̂_(i) = Enc_(B)(v_(i)).

In the event that candidate B attempts to decrypt v̂_(l), the componentIDCandidateB serves as an indicator to candidate B that they have donethe decryption successfully. The bit size of IDCandidateB should belarge enough that it is unlikely that an incorrect decryption (private)key will produce from the ciphertext v̂_(i) the valuestring||IDCandidateB.

Given that Bitcoin transactions do not have fields dedicated to thestorage of metadata, the success of the TSSV protocol is dependent onfinding a suitable location for recording the votes of the participants.Given that the design of the protocol is such that all votes arerepresented in one commitment transaction (the VCT 2), this adds somerestrictions on incorporating the set of vote commitments.

For the proposed design of the TSSV protocol, the votes are stored usingBitcoin’s script for an m-of-n multi-signature transaction. The m-of-nmulti-signature script takes the following format:

-   OP_0 Sig1 Sig2 ... NumSigs Pub1 Pub2 Pub3 Pub4 ... NumKeys    OP_CHECKMULTSIG

where the content in bold would be of the <scriptPubKey> and the contentunderlined is of the <scriptSig>. <scriptPubKey> is the ruleset thatallows for a transaction output to be utilised. <scriptSig> is thecontent required that would satisfy <scriptPubKey>. NumSigs is thenumber of required signatures, NumKeys is the number of possiblesignatures, and PubX is the public key that corresponds to the signatureSigX. While this script is intended for m-of-n signatures, the PubXelements of the redeem script may be appropriated for use as a store ofmetadata.

As an example, a 2-of-4 multi-signature script is shown where of the 4data elements reserved for Public Keys two are utilised to storemetadata. The script takes the following format:

-   OP_0 SigA SigB OP_2 metal meta2 PubA PubB OP_4 OP_CHECKMULTSIG

For our purposes, these metadata elements could be representative of theset of encrypted votes {v̂_(i): i ∈ [1, n]} of users.

As an example, a 1-of-7 multi-signature script is shown where, of theseven data elements reserved for Public Keys, five are utilised to storeencrypted votes and two for genuine public keys. The script takes thefollowing format:

-   OP_0 SigB OP_1 v̂₁ v̂₂ v̂₃ v̂₄ v̂₅ PubA PubB OP_7 OP_CHECKMULTSIG

For the current version of the Bitcoin protocol, the maximum number ofpublic keys allowable in a multisig output is 15. For this reason, themaximum number of votes (voters) that the described m-of-n script mayallow is thirteen (bearing in mind that two positions (of the 15) arereserved for the public keys of the candidates A or B). At least 2public keys are attached to each candidate (e.g. Candidate A), a mainpublic key and the collaboratively derived public key based on thek_(A,i) key shares. However, importantly, multiple m-of-n multisigscripts can be utilised within one larger script. As an example, if-elseconditions could be utilised within the script to determine whichcandidate gets paid. Each of the options within the script may have itsown m-of-n segment within the script, leading to the inclusion of atleast 26 possible votes. More elaborate scripts may be constructed toincorporate more votes, keeping in mind however, that the maximum sizeof the script is currently 10 kilobytes (as explained in more detail inBitcoin Script Interpreter-https://github.com/bitcoin/bitcoin/blob/fcf646c9b08e7f846d6c99314f937ace50809d7a/src/script/interpreter.cpp#L256) and that transaction costs are dependent on thesize of the transaction.

The use of the public key elements of the m-of-n bitcoin script requiresthat consideration be given to the size restrictions placed on of apublic key for the Bitcoin protocol. This is bearing in mind that thatthe public key is being appropriated for storing v̂_(i) where v̂_(i) is ofthe same bit length and is the encryption of v_(i) = k_(B,i)||IDCandidateB.

It should be noted that for the TSSV protocol being proposed, theBitcoin elliptic curve digital signature algorithm (ECDSA) signature(that is ultimately required for the winning candidate to claim theirfunds) requires a 256-bit private key (see, for example, Private Keyhttps://en.bitcoin.it/wiki/Private_key). To reconstruct a 256-bit (32bytes) private key requires that the key shares themselves also be 256bits in length.

The Bitcoin protocol utilises Elliptic Curve (EC) (of 256 bit length)encryption where the public key kG is a point on the curve; eachcoordinate being of 256 bits. This is described in more detail atFranco, P., 2014. Understanding Bitcoin: Cryptography, engineering andeconomics. John Wiley & Sons. The Bitcoin protocol allows forrepresentation of the EC public key as a compressed or uncompressedpoint. For the compressed point only the x-value (256 bits) of the ECpoint is stored, whereas for the uncompressed point both the x and yvalues are stored (each being of 256 bits).

The implication of this is that, if the uncompressed public key isutilised in the m-of-n script, there is enough storage space for theconcatenation of a 256-bit key share and the candidate ID. The 256 bitsof the EC point’s x-value may be used for the key share k_(B,i) whereasthe other 256 bits reserved for the y-value may be utilised to store thecandidate ID.

In voting systems, it is usually desirable that a user’s vote not betraced to the voter. For the proposed TSSV protocol, if a voter simplyadds their v̂_(i) to the set/list of existing v̂_(i)s then another votermay, on its own or collaboratively, determine the voter’s v̂_(i).Consider the case where the first voter adds their v̂_(i) to the list ofvotes. The second voter will easily be able to tell the (encrypted) votealready in the list is that of the first voter. While this only lets oneknow the ciphertext v̂_(i) and not ν_(i) itself, this puts a maliciousvoter/participant in a better position to link a voter to a v_(i).

More importantly, vote shuffling prevents the candidates (A or B) fromlinking a voter to a vote, given that the encryption of a vote is donewith a public key of one of the two candidates. If there was noshuffling, a candidate with the aid of one or more voters, may be ableto link a voter to a vote, given that a candidate can decrypt v̂_(i). Itshould also be noted that, given there being only two candidates in aTSSV protocol, a candidate not being able to decrypt a vote implies thatthe vote is for the other candidate.

For this reason, for the TSSV protocol, a shuffling solution isincorporated into the process of users providing their votes to the<scriptPubKey>. Examples of shuffling solutions are described above; anyof which may be utilised in an instance of a TSSV protocol. Thefundamental responsibility of a shuffling solution utilised for TSSVpurposes is to allow for each voter to provide their (encrypted) votewithout any other voter or non-voter being able to determine which(encrypted) vote originates from which voter.

Therefore the set of encrypted votes {v̂_(i), v̂₂, ... , v̂_(n-1), v̂_(n),}may be created without any voter or candidate (or otherwise) knowingwhich element of the set originated from which voter.

The TSSV protocol is designed in such a way that only the successfulcandidate would be able to collect the pooled bitcoins. This restrictionis facilitated by the threshold secret schemes where, for such schemes,t + 1 shares of a set of shares {k_(i): i ∈ [1, n]} may be used todetermine a secret k. t is the degree of the polynomial used tocalculate the secret key shares.

Each of the two candidates (A and B) is assigned a public key.

PubA = k_(A)G

PubB = k_(B)G

where G is the base point of the Elliptic Curve (EC) and kG is anexample of EC ‘point-multiplication-by-scalar’. G is a base point on ECand k is a scalar value.

The values of k_(A) and k_(B) are unknown (by anyone, candidate orvoter) at the earlier stages of the protocol. These k_(A) and k_(B)values can only be determined when users have submitted a sufficientnumber of votes for a particular candidate. These user votes contain akey share of k_(A) or k_(B) depending on the voter’s candidate ofchoice. The key shares of k_(A) and k_(B) are such that:

k_(A) ≡ f(k_(A, 1), k_(A, 2), ... , k_(A, n))

k_(B) ≡ f(k_(B, 1), k_(B, 2), ... , k_(B, n))

As an example, a voter’s vote commitment, if they choose to vote forcandidate B, would be

v_(i) = k_(B, i) ∥ IDCcandidateB

The value k_(B,i) is a key share of the key k_(B), a share that wouldhave been previously distributed to voter U_(i).

The distribution of key-shares in theory can be dealer-based ordealer-less. In a dealer-based distribution, the dealer knows k_(A) andk_(B) and distributes the key shares of both k_(A) and k_(B). Aparticipant in possession of a share k_(B,i) and a share k_(A,i) may beconsidered as a legitimate participant. This dealer must not be any ofthe candidates and is instead a third party. If candidates A or B weredealers, either candidate could sign the output of the TSSV, collectingall the pooled funds despite not winning the necessary votes, given thatthe malicious candidate would have known all the secret keys. For thedealer-less implementation, each voter constructs their own key share.Voters collaborate using Secret Share Joining, as described above, tocalculate the public keys PubA = k_(A)G and PubB = k_(B)G.

A PVSS scheme is utilised for candidates and voters to validate the keyshares in light of PubA and PubB. Having a dealer distribute the keyshares gives an appropriate authority control over the list of eligiblevoters; this is as the ownership of a key share can be seen as acertification of voting eligibility.

If candidate B is able to obtain sufficient votes (k_(B,i) shares),candidate B will be able to construct the secret k_(B) and utilise thisk_(B) in signing the output of the Voting Commitment Transaction 2 inorder collect the pooled committed bitcoins.

The degree of the polynomial, for an implementation of Shamir’s SecretSharing, must be chosen in light of the number of voters and the numberof votes necessary for a candidate to win. The winning candidate mustachieve the most votes and the number of votes the winning candidatereceives must also be greater than a specified threshold. As anillustration, FIG. 2 shows the number of votes necessary for a candidateto win and the degree of the polynomial for varying amounts of voters.The minimum votes necessary for the winning candidate may be higher if alarger threshold is desired. As an example, a government referendum mayrequire both a majority and at least 75% of the votes for a policyproposal to be accepted.

To collect the winnings, a winning candidate B needs to provide morethan the signature 8 b for PubB (FIG. 4 ). In addition to having beingassigned the public key PubA/PubB for which the corresponding privatekeys are split, candidates A and B both respectively possess their ownseparate (main) public keys PubA_(m) and PubB_(m). Candidate A knows theprivate key for PubA_(m) and Candidate B knows the private key forPubB_(m).

The need for this extra public key is due to the fact that any set oft + 1 voters could theoretically collaborate, calculate k_(B), and stealthe accumulated funds. This is due to the fact that there would not bethe requirement for a signature 6 b based on the extra public key - moreso its private key (corresponding to public key) which would be onlyknown to the candidate. For this reason, a signature 6 b of the winningcandidate for a public key pubB_(M) is also necessary in order for thewinning candidate (candidate B) to claim the accumulated funds.

With this in mind we consider the different ways, as per the bitcoinscript, in which the pooled bitcoins can be claimed. The <scriptPubKey>of the Voting Commitment Transaction 2 includes consideration for threeways of collecting payment.

The first of these rulesets (‘ruleset’ can be interpreted as a Booleansub-function (of the main <scriptPubKey> function) is represented in the<scriptPubKey> by the subscript

-   OP_DUP OP_HASH160 <Hash(PubS)> OP_EQUALVERIFY OP_CHECKSIG

The term subscript here is used to describe a segment of a largerscript. In this case, the larger script being referred to is the<scriptPubKey>. This script shows a basic way in which most bitcointransaction outputs are protected; it simply requires the signature forthe included public key. For the Vote Commitment Transaction (VCT) 2,this subscript controls the ability of users to obtain a refund of theircommitted bitcoins if the execution of the TSSV protocol does not go asplanned, i.e. if there is no winning selection or if the winningselection does not redeem the vote commitment transaction. Successfulsubmission of the Refund Transaction 12 to the blockchain depends on the<scriptSig> containing the signature for a public key PubS. This publickey can either be a public key that one of the voters is able to sign orit could be public key based on a separate set of distributed keyshares. For the latter option, obtaining the signature of PubS would bea collaborative effort between at least t + 1 voters to construct theprivate key and generating the signature. Note that:

-   A copy of the signed refund transaction 12 is available to all    voters prior to the VCT 2 being submitted to the blockchain.-   the Refund Transaction 12 includes an nLockTime value which prevents    the submission of the Refund Transaction 12 to the blockchain unless    a specified point in time (such as Unix time or block height) has    passed.-   the Refund Transaction 12 returns to each user the bitcoins that    user committed.

The second ruleset of these options of claiming pooled funds of the VCT2 is one such that Candidate A is able to claim the pooled fundsdepending on Candidate A’s ability to produce two required signatures 6a, 8 a (FIG. 4 ). The subscript (shown below) is a 2-of-15 multisig,i.e. it requires signatures that correspond with two public key fieldsfound within a set of fifteen public key fields. There could be fewerthan 15 fields if there are less than 13 voters.

-   OP_2 <v̂₁> <v̂₂> ... <v̂₁₂> <v̂₁₃> <PubA> <PubA_(m)> OP_15    OP_CHECKMULTSIG

This subscript serves dual purposes. The first of these responsibilitiesis to contain (at most 13 of) the encrypted votes and the second is toallow Candidate A to claim the pooled bitcoins if he is able to producethe respective signatures 8 a, 6 a of the public keys PubA and PubA_(m).PubA = k_(A)G and the signature 8 a of PubA is obtained using the secretvalues found within the v̂₁ values in order to find k_(A). This of coursedepends on there being enough votes for Candidate A within the script.Each vote for candidate A has a key share k_(A,i) and is encrypted witha public key of Candidate A (preferably PubA_(m)). PubA_(m) is a publickey generated by Candidate A and therefore Candidate A should be able toproduce the signature 6 a for this (main) public key. The signature 6 aof PubA_(m) is Candidate A’s responsibility as it was Candidate A whowould have generated PubA_(m), and would this be in possession ofPubA_(m)’s corresponding private key PrivA_(M).

The third ruleset is of similar content as the second, and is intendedto contain additional votes as well as to grant or deny Candidate B theability to claim the VCT funds based on the provision of at least twosignatures. This is shown below

-   OP_2 <v̂₁₃> <v̂₁₄> ... <v̂₂₅> <v̂₂₆> <PubB> <PubB_(m)> OP_15    OP_CHECKMULTSIG

In this case, in the m-of-n subscript, there are once again at most 13fields appropriated for votes/metadata while two fields are assigned forusage as legitimate public keys. The public keys which do in factrequire signatures are PubB and PubB_(m). PubB = k_(B)G is the publickey which corresponds with the k_(B,i) shares. At least t + 1 votes forcandidate B being present in the m-of-n scripts for Candidate B wouldallow Candidate B to utilise the k_(B,i) key shares to produce asignature 8 b for PubB. Candidate B generated PubB_(m) and thereforeshould be able to produce its signature 8 a. Provision of both of thesesignatures 8 a, 8 b would allow Candidate B to collect pooled bitcoinsof the Voting Commitment Transaction 2.

It should be noted that:

-   It does not matter in which of the two m-of-n subscripts the    encrypted votes are found; all v̂_(i) are visible in the blockchain    to both candidates, and both candidates can try to decrypt v̂_(i)    from either Candidate A or Candidate B’s m-of-n subscript, in an    effort to retrieve key shares of the their public keys for which    signatures are required.-   t + 1 is the threshold amount of votes that a candidate requires in    order to win, where t is the degree of the polynomial used in a    polynomial-based secret sharing mechanism.-   t would be chosen such that t + 1 is guaranteed to be the majority    of votes where it is a choice between two candidates.

Referring to FIG. 3 , a flowchart illustrating a process 300 embodyingthe present invention is shown. Initially, at step 302, a decision ismade on the number of voters, n. Using the key sharing techniquesdescribed above, at step 304, n shares are created for a private keyk_(A). Similarly, n shares are created for a key k_(B). These privatekeys correspond to public keys PubA and PubB respectively.

Each voter is then given a unique share k_(A,i) of k_(A) and a uniqueshare of k_(B),_(i) of k_(B) at step 306. The voters then collaborate atstep 308 using k_(A), i key shares to calculate PubA = k_(A)G usingsecret share joining, and similarly collaborate using k_(B,i) key sharesto calculate PubB = k_(B)G. PubA and PubB are then communicated at step310 to all voters and candidates and a key share scheme is used tovalidate the key shares in light of PubA and PubB. The candidates A andB then each create separate main public keys PubA_(m) and PubB_(m)respectively at step 312.

At step 314, each voter votes by concatenating its secret share with theID of its candidate of choice to provide

v_(i) = k_(B, i) ∥ IDCcandidateB

At step 316, each voter then encrypts its vote with the public key ofits candidate of choice. For example, in the case of candidate B theencrypted vote is:

v̂_(i) = Enc_(B)(v_(i))

Each voter contributes its vote to a list at step 318, this being doneusing a shuffling technique as described above so that there is no linkto the user and the vote. The voter commitment transaction 2 is thencreated at step 320. This includes inputs from each voter. Each votercontributes an amount xBTC of Bitcoin.

At step 322, the output of the voter commitment transaction 2 of thevalue nxBTC, is governed by an m-of-n script from which pubkey elementsare appropriated for their use as the stores of encrypted votes. Thisoutput script of the voter commitment transaction 2 allows for:

-   a refund of xBTC to each voter-   candidate A to collect xBTC using signatures σ(A_(m)) and σ(A)-   candidate B to collect nxBTC using signatures σ(B_(m)) and σ(B)

The refund transaction 12 is then created at step 324, signed and a copydistributed to each voter. The voter commitment transaction 2 is thensubmitted to the blockchain.

At step 326, candidate B tries to decrypt all of the v̂_(i) values. Ifthe decryption process reveals candidate B’s ID as the latter segment ofv_(i), then candidate B recognises the first segment of v_(i) as asecret share k_(B,i). If candidate B receives enough votes (shares), hecan sign the output. Candidate A carries out a substantially identicalprocess to that carried out be candidate B.

Finally, if at step 328 neither candidate is able to claim theirwinnings prior to the nLockTime of the refund transaction 12, the refundtransaction 12 is submitted, by any voter, and each voter’s committedfunds are returned to the voter, minus transaction costs.

Turning now to FIG. 7 , there is provided an illustrative, simplifiedblock diagram of a computing device 2600 that may be used to practice atleast one embodiment of the present disclosure. In various embodiments,the computing device 2600 may be used to implement any of the systemsillustrated and described above. For example, the computing device 2600may be configured for use as a data server, a web server, a portablecomputing device, a personal computer, or any electronic computingdevice. As shown in FIG. 7 , the computing device 2600 may include oneor more processors with one or more levels of cache memory and a memorycontroller (collectively labelled 2602) that can be configured tocommunicate with a storage subsystem 2606 that includes main memory 2608and persistent storage 2610. The main memory 2608 can include dynamicrandom-access memory (DRAM) 2618 and read-only memory (ROM) 2620 asshown. The storage subsystem 2606 and the cache memory 2602 and may beused for storage of information, such as details associated withtransactions and blocks as described in the present disclosure. Theprocessor(s) 2602 may be utilized to provide the steps or functionalityof any embodiment as described in the present disclosure.

The processor(s) 2602 can also communicate with one or more userinterface input devices 2612, one or more user interface output devices2614, and a network interface subsystem 2616.

A bus subsystem 2604 may provide a mechanism for enabling the variouscomponents and subsystems of computing device 2600 to communicate witheach other as intended. Although the bus subsystem 2604 is shownschematically as a single bus, alternative embodiments of the bussubsystem may utilize multiple busses.

The network interface subsystem 2616 may provide an interface to othercomputing devices and networks. The network interface subsystem 2616 mayserve as an interface for receiving data from, and transmitting data to,other systems from the computing device 2600. For example, the networkinterface subsystem 2616 may enable a data technician to connect thedevice to a network such that the data technician may be able totransmit data to the device and receive data from the device while in aremote location, such as a data centre.

The user interface input devices 2612 may include one or more user inputdevices such as a keyboard; pointing devices such as an integratedmouse, trackball, touchpad, or graphics tablet; a scanner; a barcodescanner; a touch screen incorporated into the display; audio inputdevices such as voice recognition systems, microphones; and other typesof input devices. In general, use of the term “input device” is intendedto include all possible types of devices and mechanisms for inputtinginformation to the computing device 2600.

The one or more user interface output devices 2614 may include a displaysubsystem, a printer, or non-visual displays such as audio outputdevices, etc. The display subsystem may be a cathode ray tube (CRT), aflat-panel device such as a liquid crystal display (LCD), light emittingdiode (LED) display, or a projection or other display device. Ingeneral, use of the term “output device” is intended to include allpossible types of devices and mechanisms for outputting information fromthe computing device 2600. The one or more user interface output devices2614 may be used, for example, to present user interfaces to facilitateuser interaction with applications performing processes described andvariations therein, when such interaction may be appropriate.

The storage subsystem 2606 may provide a computer-readable storagemedium for storing the basic programming and data constructs that mayprovide the functionality of at least one embodiment of the presentdisclosure. The applications (programs, code modules, instructions),when executed by one or more processors, may provide the functionalityof one or more embodiments of the present disclosure, and may be storedin the storage subsystem 2606. These application modules or instructionsmay be executed by the one or more processors 2602. The storagesubsystem 2606 may additionally provide a repository for storing dataused in accordance with the present disclosure. For example, the mainmemory 2608 and cache memory 2602 can provide volatile storage forprogram and data. The persistent storage 2610 can provide persistent(non-volatile) storage for program and data and may include flashmemory, one or more solid state drives, one or more magnetic hard diskdrives, one or more floppy disk drives with associated removable media,one or more optical drives (e.g. CD-ROM or DVD or Blue-Ray) drive withassociated removable media, and other like storage media. Such programand data can include programs for carrying out the steps of one or moreembodiments as described in the present disclosure as well as dataassociated with transactions and blocks as described in the presentdisclosure.

The computing device 2600 may be of various types, including a portablecomputer device, tablet computer, a workstation, or any other devicedescribed below. Additionally, the computing device 2600 may includeanother device that may be connected to the computing device 2600through one or more ports (e.g., USB, a headphone jack, Lightningconnector, etc.). The device that may be connected to the computingdevice 2600 may include a plurality of ports configured to acceptfibre-optic connectors. Accordingly, this device may be configured toconvert optical signals to electrical signals that may be transmittedthrough the port connecting the device to the computing device 2600 forprocessing. Due to the ever-changing nature of computers and networks,the description of the computing device 2600 depicted in FIG. 7 isintended only as a specific example for purposes of illustrating thepreferred embodiment of the device. Many other configurations havingmore or fewer components than the system depicted in FIG. 7 arepossible.

It should be noted that the above-mentioned embodiments illustraterather than limit the invention, and that those skilled in the art willbe capable of designing many alternative embodiments without departingfrom the scope of the invention as defined by the appended claims. Inthe claims, any reference signs placed in parentheses shall not beconstrued as limiting the claims. The word “comprising” and “comprises”,and the like, does not exclude the presence of elements or steps otherthan those listed in any claim or the specification as a whole. In thepresent specification, “comprises” means “includes or consists of” and“comprising” means “including or consisting of”. The singular referenceof an element does not exclude the plural reference of such elements andvice-versa. The invention may be implemented by means of hardwarecomprising several distinct elements, and by means of a suitablyprogrammed computer. In a device claim enumerating several means,several of these means may be embodied by one and the same item ofhardware. The mere fact that certain measures are recited in mutuallydifferent dependent claims does not indicate that a combination of thesemeasures cannot be used to advantage.

1. A computer-implemented method of making a decision on a blockchain,the method comprising: providing a first blockchain transaction havingan output redeemable by means of a first signature associated with aselection of a candidate by a plurality of participants and a secondsignature associated with the selection, wherein the first signature isa signature by said selected candidate; providing each of said pluralityof participants with at least one share of at least one respectivesecret value wherein a threshold number of shares is required in orderto produce said second signature; and submitting the first blockchaintransaction to the blockchain.
 2. The method of claim 1, wherein atleast one participant adds to the first blockchain transaction at leastone signed input representative of a cryptographic asset.
 3. The methodof claim 2, further comprising the step of providing a second blockchaintransaction redeemable, upon satisfaction of a locktime condition, toreturn at least a portion of the cryptographic asset to at least oneparticipant.
 4. The method of claim 1, wherein the first blockchaintransaction comprises an m-of-n multisignature redeem script, andwherein at least one share is added to the redeem script.
 5. The methodof claim 4, wherein at least one share is encrypted with a first publickey of at least one decision.
 6. The method of claim 5, furthercomprising the step of combining at least one share with identificationdata identifying a selection prior to encryption with the first publickey.
 7. The method of claim 6, wherein the combination comprisesconcatenation of the at least one share and the identification data. 8.The method of claim 1, wherein the step of providing the shares to theparticipants comprises at least one of: (i) a dealer entity providingthe shares to the participants; and (ii) the participants generating theshares among themselves.
 9. The method of claim 1, comprising the stepof obscuring which participant provides which share prior to submissionof the first blockchain transaction to the blockchain.
 10. The method ofclaim 1, further comprising the step of providing a third blockchaintransaction arranged to redeem the first blockchain transaction.
 11. Themethod of claim 1, further comprising the step of validating at leastone share using at least one second public key.
 12. The method of claim11, wherein the plurality of participants collaborate in combining atleast one subset of shares to determine at least one said second publickey.
 13. A computer-implemented system comprising: a processor; andmemory including executable instructions that, as a result of executionby the processor, causes the system to perform any embodiment of thecomputer-implemented method as claimed in claim
 1. 14. A non-transitorycomputer-readable storage medium having stored thereon executableinstructions that, as a result of being executed by a processor of acomputer system, cause the computer system to at least perform anembodiment of the method as claimed in claim 1.